iT邦幫忙

code review相關文章
共有 48 則文章
鐵人賽 Software Development DAY 7

技術 Day 7:Code Review 的舊模型為什麼追不上 AI 的產出速度

前言:「多找幾個人 review 不就好了?」 這是很多團隊面對「AI 產出太快、review 跟不上」這個問題時的第一個直覺解法:加派人手、要求更仔細的 re...

鐵人賽 AI Engineering DAY 21

技術 Day 21:案例——AI code review 抓到一個違反分層規則的隱藏耦合

前言:能動、測試也過,問題到底藏在哪 昨天講完為什麼架構審查需要獨立設計,今天用一個具體案例,把「一般 code review 看不出問題、架構審查一查就抓到」...

鐵人賽 Software Development DAY 6

技術 Day 6:「改動範圍 vs 需求範圍」——一個可以量化過度設計的指標

前言:「感覺寫得太複雜」不是一個可以放進 checklist 的標準 前幾天講了本質複雜度跟意外複雜度的區別,但這種區分方式有一個實務上的問題:它終究要靠「感覺...

鐵人賽 Vibe Coding DAY 18

技術 Day 18:授權/版權判斷——AI 不該自己決定的維護者責任

前言:這段程式碼「看起來」沒問題,就代表真的沒問題嗎? 「這個 PR 的程式碼邏輯清楚、測試也補齊了,AI 說可以合併,那應該沒問題吧?」 PHPUnit &a...

鐵人賽 AI Engineering DAY 18

技術 Day 18:案例——一條只寫在文件裡沒有工具強制的架構規則,多久會被忘記

前言:規則寫進文件那天,它最有效 「這條規則我已經寫進 CLAUDE.md 了,AI 應該會一直遵守吧?」 如果你也這樣想過,先別急著放心。昨天講到架構規則要盡...

鐵人賽 Software Development DAY 3

技術 Day 3:為什麼「測試都綠燈」不能證明程式碼設計沒問題

前言:「CI 全綠,還要 review 什麼?」 這句話幾乎是每個團隊都講過的話。測試涵蓋了主要情境、CI 顯示全綠、PR 描述寫得清清楚楚——這時候要求「再花...

鐵人賽 Software Development DAY 2

技術 Day 2:一句模糊需求,AI 怎麼生出一份「能動但過度設計」的系統

前言:「我需求講得很清楚啊,AI 亂加東西干我什麼事」 這是很多人第一次看到 AI 生出的過度設計程式碼時的直覺反應:明明只交代了一句話,AI 卻自己加了一堆...

鐵人賽 Software Development DAY 1

技術 Day 1:系列介紹——當 AI 寫得比你讀得快,Code Review 還審得完嗎?

前言:「反正有 AI,程式碼多寫一點也沒關係吧?」 這句話你大概率聽過,甚至自己講過。邏輯聽起來很合理:以前工程師手動寫程式碼很貴,一行都要斤斤計較;現在 AI...

鐵人賽 AI Engineering DAY 8

技術 Day 08:案例——AI 在沒有清楚模組邊界時,如何不小心跨模組耦合

前言:明明只是修一個小功能,為什麼牽連了另一個模組? 「我只是想讓訂單頁面多顯示一個欄位,AI 怎麼會改到用戶模組的程式碼?」 這是進入第二部後我想先處理的問題...

技術 AI 可以核准 PR 了,先別急著把它算進 Required Approval

AI reviewer 說「Approve」,PR 旁邊亮起綠色勾勾。這一刻很容易讓人誤以為工作少了一份:既然機器看過,required approval 也湊...

鐵人賽 Vibe Coding DAY 5

技術 Day 05:PR Review 交給 AI——怎麼設計給外部貢獻者的審查清單

前言:外部貢獻者的 PR,跟自己寫的 PR,能用同一套審查邏輯嗎? 「反正 AI review code 就是看程式碼寫得對不對,誰送的 PR 應該都一樣吧?」...

鐵人賽 AI Engineering DAY 8

技術 Day 8|完稿淘汰線:不問「這樣好不好」,問「刪掉會不會壞」

模組二|敘事規格化(Day 5–9) 《矽墟》是我正在寫的一部科幻小說,拆成 200 回短篇連載,整部作品用管軟體專案的方式在管:敘事結構寫成規格檔,成品用...

技術 Agent 寫的 code 要怎麼 review?先看它到底改了什麼

你看不到 agent 腦中怎麼想。 但你看得到它留下來的 diff。 這件事聽起來很廢話,卻是很多 coding agent review 討論最常跳過的一步。...

技術 公司導入 coding agent,真正該量的不是使用率

最危險的導入報表,不一定是數字不好看。 有時候剛好相反。數字太好看,才麻煩。 100 個工程師都開過 coding agent。CLI 安裝率 90%。每週 p...

技術 AI agent 沒有取代工程師,先取代的是新人練習的空間

團隊最容易丟給 AI agent 的工作,剛好也是新人最需要碰的工作。 小 bug。小 UI。文件整理。測試補一補。把某個舊元件拆乾淨。幫圖片工具補一個預覽狀態...

技術 AI agent 的新成本不是 token,而是你開始管理一群看不見的工時

早上開三個 agent run,很容易讓人有一種錯覺。 一個去修測試,一個去整理 API 回傳格式,一個去把舊元件搬到新的資料流。你去開會,吃飯,處理 Slac...

技術 AI coding agent 的下一步不是更會寫 code,而是更容易被查帳

一個 agent PR 看起來可以很漂亮。 有清楚的 commit。有像樣的 PR description。有測試結果。Diff 也不大,甚至比某些人類同事更有...

技術 AI agent 的 PR 被退,不是因為它不會寫 code,而是你沒有先定義什麼值得修

一個 AI agent 送出 PR,測試有跑,描述也寫了,diff 看起來還算乾淨。 然後 reviewer 還是把它退掉。 這件事一點都不矛盾。真實工程流程不...

技術 AI code review 開始吃 Actions minutes:review automation 其實是基礎設施成本

AI code review 最容易被誤解的地方,是它看起來像多了一個 reviewer。 PR 開了,機器人跑來留 comment。某段邏輯可能有 bug,某...

技術 CLI agent 的下一步不是更會聊天,而是更像一個可治理的執行環境

很多人看 CLI 裡的 AI 工具,第一個反應還是:「這不就是把聊天機器人塞進終端機嗎?」 這個理解大概已經過期了。 比較值得盯的變化,不是模型在命令列回答得更...

技術 讓 AI 修 CI 之前,先定義什麼叫做修好了

AI 幫你修 CI,聽起來很像一個很單純的省時間功能。 Workflow 紅了,log 一大串。你按一下 Fix with Copilot,agent 去看錯誤...

技術 Day 3:又是「請重寫」,Code Review怎麼變成單方面處刑?

禮拜三晚上八點,阿偉傳訊息給我: 「老黃又來了,我的PR被reject了,comment就一行『這個設計違反了 SOLID 原則,請重寫。』就這樣,沒了。」 「...

鐵人賽 IT 管理 DAY 30

技術 Day 30. 如何從無到有,實踐 Code Review-系列文回顧與心得

雖然標題說要回顧,其實有點懶得回顧內容,因為每天寫真的好膩 🤣,但還是不敢相信自己堅持了三十天,我們就先不討論內容的精緻度了,以30天來說,已經超過科學上養成習...

鐵人賽 IT 管理 DAY 28

技術 Day 28. Code Review 模組化與重用性-範例篇-1。

今天將繼上一篇提到的原則,實際挑選專案中幾個範例給大家參考。 範例 1 :功能模組化。 多次出現的 DataTable 初始化邏輯,可以考慮進行模組化或提高重用...

鐵人賽 IT 管理 DAY 27

技術 Day 27. Code Review 模組化與重用性-規則篇。

在 Code Review 時,為了維持程式碼可維護性、易擴充原則,Function 的模組化與重用性為重要原則。今天將介紹撰寫程式碼時,開發人員需遵守的撰寫原...

鐵人賽 IT 管理 DAY 26

技術 Day 26. Code Review 安全性原則:CSRF、其他篇

避免 Cross Site Request Forgery(CSRF) CSRF 是一種網絡攻擊,攻擊者會在使用者已經登入的情況下,執行未授權的操作。攻擊者利...

鐵人賽 IT 管理 DAY 25

技術 Day 25. Code Review 安全性原則:XSS 篇

在整個前端開發過程中,包括 JavaScript, HTML, CSS 以及與後端的交互作用,安全性的考量在各個層面都至關重要。以下將針對不同語言在程式碼安全性...

鐵人賽 IT 管理 DAY 24

技術 Day 24. Code Review 可維護性與易讀性:Todo Tree 輔助工具篇

今天要介紹 VSCode 中,可讓註解更清楚的輔助 extension- Todo Tree。 如何使用 Todo Tree 提高程式碼易讀性? Todo...

鐵人賽 IT 管理 DAY 23

技術 Day 23. Code Review 可維護性與易讀性:Better Comments 輔助工具篇

今天要介紹 VSCode 中,可讓註解更清楚的輔助 extension- Better Comments。 如何使用 Better Comments 提高程式碼...

鐵人賽 IT 管理 DAY 22

技術 Day 22. Code Review 可維護性與易讀性:註解撰寫規則篇

為什麼需要寫註解? 雖然理想中的 Clean Code 應該具備自我解釋的能力,但實際在開發過程中,撰寫註解仍然是必要的,特別是在協作開發和專案交接的情況中。...